Plasma processing has continued to evolve as manufacturing companies attempt to stay competitive in the semiconductor industry. To gain a competitive edge, manufacturers have to be able to effectively and efficiently troubleshoot problems that may arise. Troubleshooting the problems generally involves analyzing data collected during processing.
In plasma processing, data is being continuously collected by a plurality of sensors. As discussed herein, sensor refers to a device that may be employed to detect conditions and/or signals of a plasma processing component. For ease of discussion, the term “component” will be used to refer to an atomic or a multi-part assembly in a plasma processing system. Thus, a component may be as simple as a gas line or may be as complex as the entire process module.
The type and amount of data that are being collected by the sensors have increased in recent years. However, more data has not, in some cases, translated into more efficient and effective troubleshooting. Instead, the end-users of the process data are usually faced with a huge volume of data that is difficult to read and understand. In addition, the data from various data sources may be stored in different locations, making retrieval of relevant data stream files a long and arduous task. Further, correlating data between data stream files may be difficult, since a common key may not be available.
To facilitate discussion, FIG. 1 shows an overall logic view of how a host server interacts with plasma processing components (e.g., tools and subsystems) and sensors to collect different types of data. A host 102 may be receiving data from a plurality of tools, including tool 104, tool 106, and tool 108. Tools may include, but are not limited to, etch tools, clean tools, and strip tools. Each tool may have subsystems (110, 112, and 114). Subsystems may include, but are not limited to, electrostatic subsystems, RF subsystems, and pressure subsystems. Each tool and/or subsystems may include a plurality of sensors (120, 122, 124, 126, 128, 130, 132, 134, 136, 138, 140, 142, 144, 146, 148, 150, and 152). Some tools and/or subsystems may have more sensors than other. The sensors that may be available may depend upon the type of data that may be collected.
The data that are collected by the sensors are sent to host 102. The data that are collected are usually not correlated with one another. In an example, sensors 120 may be collecting RF time data while sensor 122 may be collecting pressure data during the etching of a substrate. However, the process data collected by sensors 120 and 122 may not have a key that may allow the data collected by sensor 120 to be correlated with the process data collected by sensor 122. Thus, even though an immense amount of data may be have been collected during the etching and/or cleaning of the substrate, the application of the process data toward troubleshooting a problem may be an arduous and complex task.
Troubleshooting a problem may depend upon the knowledge and skillset of the end-users (e.g., process engineers). In other words, the end-users first have to determine the problem and then identify the type of process data that may be relevant in resolving the problems. To further complicate the situation, not all relevant data may have been collected, despite the vast amount of data that may have been collected. Thus, the end-users may have the challenge of determining how to compensate for the missing data.
As a result, the complex task of troubleshooting a problem usually involves a lot of time and effort. For example, time is required to retrieve the necessary data stream files. Time is also required to mine the data stream files for the relevant data. Time is further required to determine the correlation between the data of the various data stream files. Thus, the process of troubleshooting may sometimes take weeks if not months to resolve. In some circumstances, the time required to troubleshoot a problem may exceed the time given to resolve the problem.
FIG. 2 shows a simple flow chart of what an end-user may have to perform in order to troubleshoot a problem. Consider the situation wherein, for example, a de-chuck problem may have occurred. At a first step 202, a de-chuck problem has been detected via an alignment data stream in the transfer module. In an example, a substrate is not sitting stable on the chuck and the robot arm of the transfer module may be unaligned. In the de-chuck situation, an experienced and skilled process engineer may realize that there may be four independent data stream files that may need to be retrieved in order to help with the troubleshooting. The four independent data stream files may include, for example, (1) dynamic alignment data from the transfer module, (2) electrostatic (ESC) process data from the process module, (3) event data from process module and/or user interface, and (4) process module consumable data.
As mentioned above, the data stream files may be located in various locations. Thus, the task of retrieving the data may require some time. In some circumstances, the retrieval process may take a few weeks if the data needs to be requested from other human administrator. At a next step 204, the end-user may have to search and locate ESC trace data for the problematic substrate in process module process data stream file. At a next step 206, the end-user may search and locate control event timing data via process module and/or user interface event data stream file. At a next step 208, the end-user may retrieve process module consumable data (RF times, wafer count, etc.) at the time of the problem. The end-user may then attempt to correlate the various consumable data. At a next step 210, the end-user may attach the process module and/or substrate recipe context information from event and trace data stream files.
Once all the data stream files have been retrieved, the end-user may begin the arduous task of correlating the data between the various data stream files. One common method of correlation is to compare the time the data has been collected. However, since process data may have been collected at different frequencies (e.g., sensor 120 may have collected data at every 1 second while sensor 122 may have collected data at every 500 milliseconds), the task of correlating the data based on time may be a daunting challenge. Consequently, troubleshooting a problem may become a long drawn-out process that may sometimes result in unsatisfactory conclusion.